Support parameterized circuits in QASM3 export#159
Conversation
1e04495 to
10e1693
Compare
|
Rebased onto current The conflicts came from #160, which also touched All circuit tests pass, including both |
10e1693 to
719b5b2
Compare
719b5b2 to
85275c1
Compare
|
Updated this PR to address the maintainer request around What changed:
Verification:
|
| reg_t qubit_map_; // qubit map caused by transpiling | ||
| std::vector<std::pair<uint_t, uint_t>> measure_map_; // a list of pair of qubit and clbit for measure | ||
|
|
||
| static void check_parameterized_gate_result(const QkExitCode result) |
There was a problem hiding this comment.
I think checking duplicate parameter symbols is not needed, just document this limitation is fine,
because overhead of copying quantum circuit here will be large for some cases
There was a problem hiding this comment.
Thank you, you are right. I removed the duplicate-symbol preflight copy/check path and documented the limitation instead. Distinct Parameter objects that share a name now collapse to one shared symbol, so the exported OpenQASM 3 remains valid but binds the colliding gates to the same input. I also updated the release note and replaced the rejection test with a test that documents this behavior. Please kindly review the update.
|
Thank you for the kind words. PR #159 updated. |
doichanj
left a comment
There was a problem hiding this comment.
Looks good to me.
Thank you for your contribution.
Summary
Closes #146.
This moves the OpenQASM 3 export implementation out of
QuantumCircuitinto a dedicated exporter while keeping the publicQuantumCircuit::to_qasm3()API. It also adds support for exporting parameterized circuits by emitting symbolic parameters as OpenQASM 3input float[64]declarations.What changed
src/circuit/qasm3_exporter.hppand delegateQuantumCircuit::to_qasm3()to it.input float[64]declarations before registers and operations.stdgates.incglobals, and custom gate definitions emitted by the exporter.qregister export behavior.gphase).Known limitations
The current Qiskit C API exposes the number of circuit parameter symbols but not an iterator over their names, so the exporter derives parameter identifiers from the string form returned by
qk_param_str(). This supports normal symbolic parameters and expressions, but parameter names should be OpenQASM-identifier-like.Some expression forms emitted by Qiskit's parameter string representation, such as power expressions (
theta**2) or function calls (sin(theta)), are not currently round-trippable throughqiskit_qasm3_import. The exporter preserves the expression spelling instead of rewriting it to a form that may change semantics.Testing
make -C test/deps/qiskit ccmake -S test -B /tmp/qisk146-hermes-review60-buildcmake --build /tmp/qisk146-hermes-review60-build -j20ctest --test-dir /tmp/qisk146-hermes-review60-build --output-on-failure/tmp/qisk146-hermes-review60-build/test_driver test_circuitgit diff --check origin/main...HEADqiskit 2.4.1/qiskit-qasm3-import 0.6.0usingqiskit.qasm3.loads()for reserved-name conflicts, keyword/constant-name conflicts, classical-register conflicts, controlled-U definitions, and global phase output.AI assistance disclosure
I used Codex, Claude, and Hermes as AI assistants to help prototype, review, compare related approaches, and draft PR text. I manually reviewed the resulting diff, checked the live GitHub issue/PR state and unitaryHACK policy, refined the implementation, and ran the tests listed above locally. The PR is submitted with human oversight; any remaining mistakes are mine.